This invention relates generally to the field of computer graphics. More particularly, the invention relates to performing 3D graphics operations efficiently in a networked environment.
OpenGL in Networked Environments. OpenGL is a standard application programmer""s interface (xe2x80x9cAPIxe2x80x9d) to hardware that accelerates 3D graphics operations. OpenGL is intended to be used with window systems such as the X Window System. In order that OpenGL may be used in an X Window System environment, an extension to the X Window System has been developed called GLX. For more complete information on the GLX extension to the X Window System and on how OpenGL can be integrated with the X Window System, see for example Mark K. Kilgard, OpenGL Programming for the X Window System (Addison-Wesley Developers Press 1996).
FIG. 1 illustrates a typical prior art implementation wherein single-screen 3D accelerated graphics operations are performed over a network in an X Window System environment. Two computer systems are used. Client host 100 is connected to server host 102 via LAN 104 or some other suitable network or system connection. As can be seen from the drawing, three processes are running on hosts 100 and 102: An OGL/X client process 1806 runs on client host 100. An X server process 108 and an OGL daemon process 110 process run on server host 102. (For more information on this three-process model, see Kevin T. Lefebvre, et al., xe2x80x9cAn Overview of the HP OpenGL Software Architecture,xe2x80x9d Hewlett-Packard Journal Vol. 49, No. 2, pp. 9-18 (May 1998), which article is hereby incorporated by reference in its entirety.) X server process 108 is one that includes the GLX extension. Both OGL/X client 106 and OGL daemon 110 have an OpenGL implementation that includes a device independent (xe2x80x9cDIxe2x80x9d) OGL layer 112 and a device dependent (xe2x80x9cDDxe2x80x9d) OGL layer 114.
The purpose of OGL DI layer 112 and OGL DD layer 114 is to execute OpenGL commands and to drive 3D accelerated display hardware 116. OGL DI layer 112 has one set of routines for local rendering and another set of routines for rendering over network 104. The local versus remote modes are initialized by loading pointers to the desired set of routines in a dispatch table in OGL/Xlib dispatch layer 118. Each OGL command that comes from application 120 will point to a particular entry in the dispatch table. By placing a different pointer in that entry, a different routine may be used to implement the OGL command corresponding to that entry. (For a more detailed discussion of this kind of dispatch table indirection, see for example U.S. Pat. No. 5,321,808, titled xe2x80x9cDual Process Display Server,xe2x80x9d by Lawrence E. Rupp, which patent is hereby incorporated by reference in its entirety.)
In the example of FIG. 1, if the local mode is chosen, then OGL commands issued by application 120 will be rendered directly on the display hardware 116 that is coupled to host 1800. But if the remote mode is chosen, as it would be in a networked environment, then OGL commands issued by application 120 will be routed to X server process 108 using the GLX extension protocol. From there, they are routed to OGL daemon process 110 which executes them and renders the result on the display hardware 116 coupled to server host 102.
Network Bandwidth Conservation. When OpenGL is being used in remote mode in a networked environment such as that shown in FIG. 1, it is common for a great deal of traffic to pass from client host 100 to server host 102 over network connection 104. This is particularly true in single-logical-screen applications wherein a single client host issues commands to numerous server hosts over the network. For this reason, network bandwidth can become an important performance limiter in many applications.
Command Buffering. One technique that has been employed in the past to conserve network bandwidth in this context has been the technique of buffering OpenGL commands within client host 100 before they are transmitted to server host 102. For example, in FIG. 1, outgoing commands are buffered within client-side OGL command buffer 122, which buffer is created and managed by client-side GLX library 123. On the server side, incoming OGL commands are buffered in server-side OGL command buffer 124. GLX extension 125 within X server process 108 creates, manages and fills server-side shared memory OGL command buffer 124. OGL daemon 110 has a shared memory connection to OGL command buffer 124, as shown at 126. It uses shared memory connection 126 to read OGL command buffer 124 so that it can execute the commands stored therein. A direct inter-process connection between OGL daemon 110 and X server process 108 also exists, as shown at 126. Using direct inter-process connection 126, X server process 108 can, for example, communicate to OGL daemon 110 when shared memory OGL command buffer 124 is ready to be read.
A typical server-side process for receiving and consuming command buffers is summarized in the flow diagram of FIG. 2. In step 200, a new command buffer is received in server host 102. Steps 202, 204 and 206 represent a loop wherein a server side process repeatedly extracts commands from the received command buffer one at a time and executes them. When the buffer is completely consumed, a new buffer is received again in step 200.
In higher-end applications requiring very high network bandwidth, multiple command buffers may be employed to further enhance performance. Such a multiple-buffer arrangement is described by Kevin Lefebvre, et al. in U.S. patent application Ser. No. 09/138,456, filed Aug. 21, 1998, titled xe2x80x9c3D Graphics in a Single Logical Screen Display Using Multiple Remote Computer Systems,xe2x80x9d now U.S. Pat. No. 6,249,299, which patent application is hereby incorporated by reference in its entirety.
Creation of Array Function Calls Downstream of the Application. Another technique that has been used to conserve network bandwidth has been the technique of converting vertex function calls issued by application software 120 into array function calls before transmitting them to server host 102. Not only do array function calls conserve network bandwidth relative to vertex function calls, but they also yield faster rendering performance.
FIG. 3 is a flow diagram illustrating this technique according to a method described by Roland Hochmuth, et al. in U.S. patent application Ser. No. 09/302,659, filed Apr. 30, 1999, titled xe2x80x9cAdaptive Buffering of Computer Graphics Vertex Commands,xe2x80x9d now U.S. Pat. No. 6,337,689, which patent application is hereby incorporated by reference in its entirety. Among the OpenGL commands issued by application software 120 are: (1) vertex API commands 300, also known as xe2x80x9cVAPI commands,xe2x80x9d such as glBegin, glVertex and glEnd; (2) glDrawArrays commands 302; and (3) glDrawArraySet commands 304. VAPI command routines 306 are used to buffer the information contained in VAPI commands 300 into data structures that can be used by a glDrawArrays function call. Similarly, glDrawArrays command routines 308 are used to buffer information contained in glDrawArrays commands 302, as well in the structures created by VAPI command routines 308, into data structures that can be used by a glDrawArraySet function call. Finally, glDrawArraySet routines 310 buffer glDrawArraySet function calls into client-side command buffer 122. Periodically, client-side command buffer 122 is flushed to one or more server hosts 102 using network connection 104.
The functionality of VAPI routines 306 is described in more detail by Hochmuth et al., supra, at FIGS. 3-4 therein and in the accompanying text. The functionality of glDrawArrays routines 302 is described in more detail by Hochmuth et al., supra, at FIGS. 5-14 therein and in the accompanying text. The functionality of glDrawArraySet routines 310 is described in more detail in both Hochmuth et al., supra, and in the Lefebvre et al. patent application Ser. No. 09/138,456, supra.
Immediate Mode Versus Display List Mode in OpenGL. OpenGL commands can be issued for immediate execution in what is called xe2x80x9cimmediate mode.xe2x80x9d Alternatively, most OpenGL commands can be stored for later execution in what is called xe2x80x9cdisplay list mode.xe2x80x9d Once a series of OpenGL commands has been stored in a display list, the series of commands can be called later for execution by issuing a single command that simply identifies the list. Thus, display list mode represents yet another technique for conserving network bandwidth in an environment like that shown in FIG. 1: The display list itself is stored in server host 104. To execute the commands in the list, client host 100 needs only to transmit a single glCallList command over network 104. That is why, once a display list has been created in server host 104, significant network bandwidth is preserved each time the display list is called. Unfortunately, not all application software uses display list mode.
Objects of the Invention. It is therefore an object of the invention to preserve network bandwidth between a client host and a server host in the context of performing computer graphics operations.
It is a further object of the invention to preserve network bandwidth between a client host and a server host when application software in the client host issues OpenGL commands in immediate mode.
For environments in which immediate mode graphics commands are sent by a client host across a network for execution by a server host, the invention improves performance by caching immediate mode commands inside the server host. It is believed that the invention will yield the highest benefits when used with applications that frequently re-send data.
In an embodiment, two types of immediate mode command packets are employedxe2x80x94a full-size packet type and a truncated packet type. The full-size packet type includes a cache code field, a table index field and a data field corresponding to the command. The truncated packet type includes only the cache code field and the table index field. For certain outgoing immediate mode commands, if it is determined on the client side that the command""s data field has not previously been stored within the server host, then the client host sends a full-size packet type to the server host to indicate the command. The server host executes the command and stores the command""s data field in its own memory for possible later use. But if it is determined on the client side that the command""s data field has previously been stored within the server host, then the client host sends only a truncated packet type to the server host to indicate the command. In the latter case, the server host executes the command by recalling a previously-stored data field responsive to the table index supplied in the truncated packet.